\chapter{Étude des besoins}

\section{Besoins fonctionnels}

Nous allons tout d'abords introduire un peu de vocabulaire afin de définir par la suite, la liste des besoins fonctionnels.

\subsection{Quelques définitions}

Un \textit{utilisateur} est la représentation virtuelle d'une personne physique. Chaque utilisateur de la plateforme est lié à un compte. Ce compte possède un des statuts suivants :
\begin{itemize}
\item \textit{Administrateur}
\item \textit{Enseignant}
\item \textit{Étudiant}
\end{itemize}

\paragraph*{}

Un \textit{template} représente un patron. De manière simple, on peut voir ce concept comme un \textit{type} (ou un \textit{modèle}) de projet. Chaque \textit{template} possède une description, une batterie de tests disponibles relatifs, d'autres informations diverses.

Un \textit{assignment} est la concrétisation d'un \textit{template}. C'est la représentation du projet en lui même.

Un \textit{assignment submission} représente l'état actuel d'un projet pour un groupe d'étudiants.

Une \textit{Warehouse} est un emplacement réel dans le système de fichier qui servira d'espace de stockage.



\subsection{Les individus et leurs rôles}

Il sera possible de définir des groupes d'utilisateurs. Un groupe se caractérise par le fait que tous ses membres possèdent les mêmes privilèges pour un \textit{assignment} donné.

\subsubsection{L'administrateur}

L'administrateur est le gestionnaire de la plateforme. Il peut :
\begin{itemize}
\item Effectuer des opérations sur les \textit{template} (création, suppression, modification)
\item Effectuer des opérations sur les groupes d'utilisateurs (création, suppression, modification)
\item Modifier les fonctionnalités de la plateforme comme ajouter des modules de tests par exemple
\end{itemize}

\subsubsection{L'enseignant}

L'enseignant est un utilisateur pouvant avoir différents statuts :
\begin{itemize}
\item \textit{Supervisor}
\item \textit{Advisor}
\end{itemize}

\paragraph*{}

Un \textit{supervisor} gère un \textit{assignment} (ajout de contraintes, définition des règles, etc...). Il peut affecter des \textit{advisor} à des groupes d'étudiants.
Il possède les droits de l'ensemble de ses \textit{advisor} sur l'\textit{assignment} concerné.

\paragraph*{}

Un \textit{advisor} est responsable d'un groupe d'étudiants sur un \textit{assignment} donné. Il peut :

\begin{itemize}
\item Créer ses propres scripts de tests sur un \textit{assignment}, ou sur un ensemble d'\textit{assignment} (tests de comparaison)
\item Créer des tests pour les étudiants concernés
\item Définir le formatage de sortie des tests
\item Ajouter ou supprimer des étudiants d'un groupe
\end{itemize}

\subsubsection{L'étudiant}

L'étudiant peut être rattaché à un ensemble de groupe. Chacun de ses groupes est relatif à un \textit{assignment} donné et à un \textit{advisor}.\\

Les groupes d'étudiants (ou un étudiant seul dans le cas d'un projet individuel) peuvent :
\begin{itemize}
\item Soumettre leur version actuelle du projet (\textit{assignment version}) à une batterie de tests. Ces tests sont définis par l'\textit{advisor} (ou par le \textit{supervisor}) concerné
\item Enregistrer leur projet comme version finale
\end{itemize}


\subsection{Les tests}

Les tests sont de plusieurs types :
\begin{itemize}
\item Test enseignant
\item Test étudiant
\item Test de comparaison
\end{itemize}

\paragraph*{}

Un test \textit{enseignant} est un test permettant à un \textit{advisor}(ou \textit{supervisor}) d'obtenir une évaluation sur un \textit{assignment version}. Ce test est représenté par un script faisant appel à différentes fonctions de tests, disponibles pour le \textit{template} courant. Le script prévoit aussi une configuration sur le formatage de sortie.\\

Un test \textit{étudiant} est un test qui sera utilisé lorsque des étudiants voudront tester leur version actuelle du projet. Cela leur permettra d'avoir un retour sur la qualité, et sur les points à améliorer de leur travail en temps quasi immédiat.\\

Un test de \textit{comparaison} est un test disponible pour l'enseignant afin de comparer des \textit{assignment version} entre eux en vue d'un classement ou d'une moyenne.\\

Chaque test effectué possède un poids (par défaut 1). Cela permettra de rendre certains tests plus importants que d'autres dans la mesure ou le format de sortie serait une moyenne de tous les tests.
Les différents scripts seront écris en Python. Les appels aux fonctions seront fait grâce à une bibliothèque extensible de tests.\\

%Certains modules de tests seront fournis avec la plateforme :
%\begin{itemize}
%\item .
%\end{itemize}


\subsection{Interfaces}

L'application sera composé d'un cœur sur lequel il sera possible de brancher plusieurs interfaces.
Nous fournirons deux interfaces par défaut.

\subsubsection{Ligne de commande}

Cette interface sera réservée aux administrateurs et au développeurs. L'application sera exécutée en local et aucun mécanisme de droit ne sera implémenté. Elle permettra de gérer directement les données.


\subsubsection{Plateforme Web}

La plateforme WEB sera l'interface de référence pour les utilisateurs réguliers (étudiants, enseignants).
Elle disposera de sa propre base de donnée afin de stocker les informations temporaires (celles relatives aux tests étudiants par exemple).
Un mécanisme de droit sera implémenté de manière à prévenir toute opération non permise de la part d'un utilisateur. L'interface WEB sera adaptée aux fonctionnalités offertes à chaque type d'utilisateurs.


\subsection{Stockage}

Les \textit{template} seront conservés dans une \textit{warhouse}.
Il en sera de même pour l'ensemble des \textit{assignment version} d'un groupe d'étudiant pour un projet donné.


\section{Besoins non fonctionnels}

Un des premiers besoins non fonctionnels se réfère au langage d'implémentation. En effet, le client souhaite que l'implémentation soit réalisé en Python.

Parmi les avantages de ce langage, nous pouvons citer\cite{Pro62}:

\begin{itemize}
\item Python est un langage multi-paradigme, ainsi nous aurons la possibilité de programmer en orientée objet ou en impératif selon les besoins
\item Le typage dynamique nous épargne de toute gymnastique de déclaration de type
\item La gestion de la mémoire est dite "ramasse-miettes". Donc inutile ici de se pré-occuper de la gestion mémoire (utilisation/libération)
\item Python possède un système d'exceptions, très utile dans la conception de projet important, notamment au niveau de la robustesse
\item Sa particularité d'être interprétable nous évite de se pré-occuper d'une quelconque compilation (bien que Python puisse aussi être compilé, et qu'en générale, l'interprétation est plus lente...)
\item Le FrameWork web que nous utiliserons (Django) est aussi écrit en Python.
\end{itemize}

\paragraph*{}

Ainsi, beaucoup d'aspects favorisent un gain de temps (typage, gestion mémoire, compilation), primordial au vu du temps qui nous est imparti dans la conception de SPASS.

\subsection{Les Interfaces}

Le programme devra pouvoir être connecté sur une interface différente de celles que nous proposons par défaut. Pour se faire, nous fournirons une API Python de dialogue avec le cœur permettant ainsi à l'administrateur de créer lui même ses propres interfaces.\\

Il existe également des contraintes relatifs à nos interfaces.

\subsubsection{L'interface en ligne de commande}

Celle ci doit être modulaire. En d'autres termes, il doit être possible de créer facilement de nouvelles commandes. Nous nous inspirerons de l'outil \textit{bazaar} (GNU GPL v3) qui propose un système pour cela.

\subsubsection{L'interface Web}

Cette interface doit être la plus intuitive possible. 
Les utilisateurs ne doivent avoir accès qu'aux outils dont ils ont l'autorisation de se servir.
Les résultats des tests devront être consultable au sein de cette interface.
Les groupes devront pouvoir être formé à partir de l'interface web de la manière la plus flexible.

\subsection{Les tests}

L'application devra permettre à l'administrateur de pouvoir rajouter des modules de tests supplémentaires (comme un détecteur de plagiat par exemple).

Les scripts de tests devront permettre d'appeler les modules de tests (grâce à l'API) dans un certain ordre. Certain pourront provoquer l'arrêt de l'exécution du script si ils échouent.


Il faudra pouvoir mettre en place un environnement d'exécution adéquat vis à vis du programme testé/exécuté. Il s'agira notamment d'allouer un certain nombre de ressources matérielles.

La phase de test devra être faite dans un environnement sécurisé de manière à préserver l'intégrité de la plateforme et du serveur.
Cet aspect nécessite un long travail de réflexion, sur la manière d'exécuter un programme suspecté douteux, et cela de manière entièrement sécurisé (virtualisation, droits restreints, etc...).
